Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000166_owner-urn-ietf _Thu Nov 14 14:09:00 1996.msg

Internet Message Format | 1997-02-19 | 6KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA26505 for urn-ietf-out; Thu, 14 Nov 1996 14:09:00 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA26500 for <[e-mail]>; Thu, 14 Nov 1996 14:08:57 -0500
Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA21876  (mail destined for [e-mail]); Thu, 14 Nov 96 14:07:38 -0500
Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id MAA08538 for <[e-mail]>; Thu, 14 Nov 1996 12:07:21 -0700 (MST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 14 Nov 1996 12:15:35 -0700
To: [e-mail]
From: Ron Daniel <[e-mail]>
Subject: [URN] text/uri-list registration
Sender: [e-mail]
Precedence: bulk
Reply-To: Ron Daniel <[e-mail]>
Errors-To: [e-mail]

Hi,

One of the changes to the "conventions" draft was using text/uri-list
instead of text/plain as the media type for lists of URIs that would
be returned by requests such as N2Ls. Here is my first stab at the info
required to register that type. Any comments before I send it in?

=====================

1. MIME type name: text


2. MIME subtype name: uri-list


3. Required Parameters: None


4. Optional Parameters: charset

   Charset handling for URIs is currently being discussed. This
   registration shall be updated with a discussion of the interaction
   of the charset parameter and the upcoming URI charset rules once
   that interaction is understood.


5. Encoding Considerations:
  URI encodings are already specified in RFC 1630, ... The URIs
  in the text/uri-list shall conform to those documents. The URI
  encoding rules allow for URIs to be made mail-safe, so additional
  encoding should not be necessary.


6. Security Considerations:
  Client software should be aware of the security considerations of URIs.
  For example, accessing some URIs can result in sending a death threat to
  a head of state, perhaps spurring a visit from the relevant protective
  service.  Accessing other URIs may result in financial obligations.

  While the legitimate provider of a uri-list can exploit these properties
  for good or ill, they make uri-lists an attractive target for spoofing.
  Further, the lookup and reverse lookup potential of the uri-list may be
  attractive to traffic analysts. URI lists may also reveal confidential
  information, such as the location of sensitive information.

  Because of these considerations, external confidentiality measures should
  be available to protect uri-list responses when appropriate.


7. Interoperability considerations:

   none?


8. Published Specification:

Uniform Resource Locators (URLs) and Uniform Resource Names (URNs) are
two instances of the more general class of identifiers known as
Uniform Resource Identifiers (URIs). URN resolution methods typically
wish to return lists of URLs for a resource so that fault-tolerance and
load balancing can be achieved. The text/uri-list format is intended to
be a very simple format for communicating such lists of URLs (and URNs)
in a form suitable for automatic processing.

The format of text/uri-list resources is:
1) Any lines beginning with the '#' character are comment lines
   and are ignored during processing.
2) The first non-comment line shall be an integer giving the number of
   URIs in the list.
3) The remaining non-comment lines shall be URIs (URNs or URLs), encoded
   according to the URI specification (RFC 1630). Each URI shall appear on
   one and only one line.
4) As for all text/* formats, lines are terminated with a CRLF pair.

In applications where one URI has been mapped to a list of URIs, the
first line of the text/uri-list response SHOULD be a comment giving the
original URI.

An example of the format is given below:

     # urn:cid:[e-mail]
     3
     http://www.huh.org/cid/foo.html
     http://www.huh.org/cid/foo.pdf
     ftp://ftp.foo.org/cid/foo.txt


9. Applications which use this media type:

URN resolvers are the initial applications. Web clients and
proxies are applications that are likely to support this format
in the future.


10. Additional Information:
a) magic number(s)
   none presently

b) file extension(s)
   .uris or .uri recommended

c) Macintish File Type Code(s)
   none presently - "URIs" recommended if no conflict with existing codes?

d) Object Identifier(s) or OID(s)
   none presently  (Should we try to get one or blow it off for now?)

11. Person to contact for further information:
 Name) Ron Daniel  [Of course if someone else wants this...]
 email) [e-mail]

12. Intended usage:
 Common?  Limited use?  [I'm asking for advice here]

13. Author/change controller
  Ron Daniel, [e-mail]  [Of course if someone else wants this...]

========
Regards,
Ron Daniel Jr.                       email: [e-mail]
Advanced Computing Lab               voice: [phone]
MS B287                                fax: [phone]
Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, USA  87545    obscure_term: "hyponym"